Layout automation with python¶

Thomas Ferreira de Lima¶

NEC Labs America, Princeton, USA

June 6, 2022

https://github.com/thomaslima/2022-SiEPIC-workshop-zeropdk

Email: thomas@nec-labs.com

Outline¶

  • Motivation for procedural layout
  • Basic definitions
  • Tool requirements
    • KLayout
    • Python/Docker
  • An overview of Zeropdk
  • Demo preparation
  • Using SiEPIC with Zeropdk
    • Demo 1: Using SiEPIC cell library
  • Hierarchical layout
    • Demo 2: MZI PCell
  • Advanced layout techniques:
    • Geometry unit testing (lytest)
    • Visual debugging (lyipc)
    • Version control and collaboration
    • Outlook (help needed with DRC, SiEPIC and docs)

Motivation for procedural layout¶

  • GDSII is the industry standard file format for IC layout.
  • It organizes geometry in polygons, cells, and cell references.
  • However, it is quasi-binary: understood by machines, useless to humans.
  • There is no support for parameters, design intent, comments, connectivity, physical data.
  • Poor representation of curves

GDS has problems with curves¶

image.png

GDS does not capture logical relation¶

image.png

image.png

Procedural vs. Computer-aided¶

  • Computer-aided layout

    • Interactive: designer sees what’s happening at all times
    • Intuitive
    • No software bugs
    • Macros: some benefits of procedural

  • Procedural layout

    • Completely repeatable
    • Easy to apply global changes
    • Easy to version a chip, not just a library
    • Full record of design intent

IC design “by hand”, aided A LOT by computer¶

image.png

Procedural IC design today¶

image.png

What is new?¶

  • Photonic integration
  • High-level languages (Python)
  • Free software infrastructure

Difference with macros¶

  • Procedural means 100% coded
  • Push a button, GDS comes out
  • This means entire chips are defined 100% by source code
    • repeatable
    • human understandable
    • arbitrarily complex
    • more easily version controlled

Example from one of our chips¶

# make_chip.py

FLOORPLAN_SAFE = 50
TECHNOLOGY = TECHNOLOGY.layers  # TODO refactor

if __name__ == "__main__":
    layout = pya.Layout()
    dbu = layout.dbu = 0.001
    TOP = layout.create_cell("TOP")

    origin = pya.DPoint(0, 0)
    ex = pya.DVector(1, 0)
    ey = rotate90(ex)

    # FLOORPLAN
    FX, FY = 7850, 3000  # um
    layout_box(TOP, layout.layer(TECHNOLOGY["FloorPlan"]), 
               origin, origin + FX * ex + FY * ey, ex)

    # Placing each experiment
    placement_list = {
        "FeedbackWeightBank_experiment": (
            exp.FeedbackWeightBank_experiment, # PCell class
            2792.04000, 328.87000,             # position
            {"angle_ex": 90, "N": 5},          # parameters
        ),
    # ...
    }

    # Place all PCells in placement_list and export port locations for routing
    for name, (klass, x, y, params) in placement_list.items():
        exp_ports[name] = klass(name, params=params).place_cell(
                TOP, x * ex + y * ey
            )
    # ...

    # Perform routing using exp_ports dictionary
    # ...

    # Removing the $$$CONTEXT_INFO$$$ top cell (Foundries don't like it)

    save_options = pya.SaveLayoutOptions()
    save_options.write_context_info = False

    # CMC told us to have maximum cell name length of 60 characters
    save_options.gds2_max_cellname_length = 60

    layout.write("mpw-chip.gds", save_options)

Basic definitions¶

PCells¶

PCells are the foundation of layouts with more than a couple polygons

  • Rule of thumb: one pcell per device
  • Defined by code (logic) instead of points (geometry)
  • Reused to create many different geometries
  • Easy to edit
  • Can be nested

Routing elements¶

Routing elements refer to the connections between devices (drawn in PCells). They could be metal traces, optical waveguides, or I/O elements.

Ports¶

The connection between PCells and routing elements are defined in the concept of Ports. The port must contain information on the type of connection, the dimensions of the routing elemenet (e.g. waveguide width), a human-readable name, and positioning.

Tool Requirements¶

  • KLayout
  • Python modules:
    • klayout
    • zeropdk

KLayout¶

image.png

KLayout scripting¶

You probably all know KLayout, but few people make good use of the scripting documentation:

  • klayout.de » Documentation » Programming Scripts (recommend reading Database API and Geometry API)
  • klayout.de » Documentation » Reference (have it open while coding)

image.png

Python (klayout)¶

I helped Matthias to release a klayout package in PyPI. It works in a standalone way and is loaded with the Database and Geometry APIs, but not Application or Qt (yet).

pip install klayout

Currently there are pre-built wheels in the following versions:

OS Python Version
macOS 10.13+ 3.6, 3.7, 3.8, 3.9, 3.10
linux x64 3.6, 3.7, 3.8, 3.9, 3.10
win32, win64 3.6, 3.7, 3.8, 3.9, 3.10

Note for advanced users: You can attempt to build klayout from source by running python setup.py install on the cloned folder from klayout's github repo.

In [1]:
!pip install klayout

import klayout.db as pya

a = pya.DPoint(1, 2)
b = pya.DVector(0, 1)

a+b

Requirement already satisfied: klayout in /opt/homebrew/Caskroom/miniforge/base/envs/siepic/lib/python3.9/site-packages (0.27.9.post1)
Out[1]:
<klayout.dbcore.DPoint at 0x103f00740>

Python (zeropdk)¶

Our lab relies on klayout's database engine to produce masks for MPW manufacturing. To aid collaboration, we open-sourced a tool called zeropdk.

Many foundries only offer PDKs to commercial software with a steep price tag, but are happy to offer libraries of standard components in the .gds format. ZeroPDK allows you to quickly bootstrap a Photonics PDK without necessarily relying on their partners: great for academic users and students. Also great for pro users.

Zeropdk is available with pip install zeropdk and the source code is released in our github page

An overview of Zeropdk¶

  • Three submodules:
    • zeropdk.tech: helps load a tech layer definition from a lyp file.
    • zeropdk.layout: a library of tools for advanced polygon creation (round polygons, waveguides, etc).
    • zeropdk.pcell: contains standard class definitions of PCells, ports and parameters. The idea is to make it compatible with SiEPIC-Tools and Klayout Macro Editor (eventually)
  • Similarly to SiEPIC-Tools, zeropdk modifies/patches some Python bindings for klayout objects, such as SimplePolygon, Point, Vector.
  • Beta status: scarce docs (need help!)
In [2]:
!pip install zeropdk

Requirement already satisfied: zeropdk in /opt/homebrew/Caskroom/miniforge/base/envs/siepic/lib/python3.9/site-packages (20.12)
Requirement already satisfied: numpy in /opt/homebrew/Caskroom/miniforge/base/envs/siepic/lib/python3.9/site-packages (from zeropdk) (1.22.4)
Requirement already satisfied: klayout in /opt/homebrew/Caskroom/miniforge/base/envs/siepic/lib/python3.9/site-packages (from zeropdk) (0.27.9.post1)
Requirement already satisfied: scipy in /opt/homebrew/Caskroom/miniforge/base/envs/siepic/lib/python3.9/site-packages (from zeropdk) (1.8.1)
In [3]:
!ls ../demo | grep .lyp

from zeropdk.tech import Tech
EBeam = Tech.load_from_xml('../demo/EBeam.lyp')
EBeam.layers

EBeam.lyp
Out[3]:
{'Si': <klayout.dbcore.LayerInfo at 0x1180b0ec0>,
 '31_Si_p6nm': <klayout.dbcore.LayerInfo at 0x1180b0f40>,
 'Text': <klayout.dbcore.LayerInfo at 0x1180b0e40>,
 'Si N': <klayout.dbcore.LayerInfo at 0x1180b09c0>,
 'Si N++': <klayout.dbcore.LayerInfo at 0x1180b0dc0>,
 'SEM': <klayout.dbcore.LayerInfo at 0x1180b0d40>,
 'M1': <klayout.dbcore.LayerInfo at 0x1180b0cc0>,
 '12_M2': <klayout.dbcore.LayerInfo at 0x1180b0c40>,
 '13_MLopen': <klayout.dbcore.LayerInfo at 0x1180b0bc0>,
 'VC': <klayout.dbcore.LayerInfo at 0x1180b0b40>,
 'M Heater': <klayout.dbcore.LayerInfo at 0x1180b0ac0>,
 'FloorPlan': <klayout.dbcore.LayerInfo at 0x1180b0a40>,
 'DevRec': <klayout.dbcore.LayerInfo at 0x1180b0940>,
 'PinRec': <klayout.dbcore.LayerInfo at 0x1180b0040>,
 'FbrTgt': <klayout.dbcore.LayerInfo at 0x1180b00c0>,
 'Errors': <klayout.dbcore.LayerInfo at 0x1180b0140>,
 'Lumerical': <klayout.dbcore.LayerInfo at 0x1180b01c0>,
 'Waveguide': <klayout.dbcore.LayerInfo at 0x1180b08c0>}
In [4]:
import zeropdk.layout.waveguide_rounding as wav_rounding

wav_rounding.main()  # produce some interesting non-Manhattan waveguides

Wrote waveguide_rounding.gds

Contents of waveguide_rounding.gds:

image.png

In [6]:
!python ../demo/main_python.py

Wrote to example_mask.gds
In [7]:
# !open example_mask.gds

image.png

Demo 1¶

Open demo/1. Demo - Using SiEPIC cell library.ipynb

Demo 2¶

Open demo/2. Demo - MZI PCell.ipynb

Advanced layout techniques¶

One goal: enable collaboration reduce dependence on a single designer or specific computer setup.

Key questions – recommended tools¶

What is going on? – Visual debugging¶

  • Python debugger + inter-process control (github.com/atait/klayout-ipc)

Is it working? – Geometric unit testing¶

  • KLayout XOR diff program + Pytest (docs.pytest.org)

What if, oops, and collaborating – Version control¶

  • Git (www.atlassian.com/git/tutorials)

What does this thing do? – Documentation & examples¶

  • Sphinx (www.sphinx-doc.org)

What parts go where? – Modules, packaging¶

  • Read and think about it (docs.python-guide.org/writing/structure)

Procedural Layout introduces pitfalls¶

  • Completely repeatable (but opaque and not interactive)
  • Press a button, GDS comes out
  • Easy to apply global changes (and introduce subtle side-effects)
  • Easy to version and collaborate (and quietly break your friends’ stuff)
  • Full record of design intent (or messy unreadable code)

Powerpoint presentation in person. Might share here later.